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Abstract 


This document defines two autonomic technical objectives for IPv6 prefix management at the 
edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important 
purpose of this document is to use it for validation of the design of various components of the 
Autonomic Networking Infrastructure. 
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1. Introduction 


The original purpose of this document was to validate the design of the Autonomic Networking 
Infrastructure (ANI) for a realistic use case. It shows how the ANI can be applied to IP prefix 
delegation, and it outlines approaches to build a system to do this. A fully standardized solution 
would require more details, so this document is informational in nature. 


This document defines two autonomic technical objectives for IPv6 prefix management in large- 
scale networks, with an extension to support IPv4 prefixes. The background to Autonomic 
Networking is described in [RFC7575] and [RFC7576]. The GeneRic Autonomic Signaling Protocol 
(GRASP) is specified by [RFC8990] and can make use of the technical objectives to provide a 
solution for autonomic prefix management. An important purpose of the present document is to 
use it for validation of the design of GRASP and other components of the ANI as described in 
[RFC8993]. 


This document is not a complete functional specification of an autonomic prefix management 
system, and it does not describe all detailed aspects of the GRASP objective parameters and 
Autonomic Service Agent (ASA) procedures necessary to build a complete system. Instead, it 
describes the architectural framework utilizing the components of the ANI, outlines the different 
deployment options and aspects, and defines GRASP objectives for use in building the system. It 
also provides some basic parameter examples. 


This document is not intended to solve all cases of IPv6 prefix management. In fact, it assumes 
that the network's main infrastructure elements already have addresses and prefixes. This 
document is dedicated to how to make IPv6 prefix management at the edges of large-scale 
networks as autonomic as possible. It is specifically written for Internet Service Provider (ISP) 
networks. Although there are similarities between ISPs and large enterprise networks, the 
requirements for the two use cases differ. In any case, the scope of the solution is expected to be 
limited, like any Autonomic Network, to a single management domain. 


However, the solution is designed in a general way. Its use for a broader scope than edge 
prefixes, including some or all infrastructure prefixes, is left for future discussion. 


A complete solution has many aspects that are not discussed here. Once prefixes have been 
assigned to routers, they need to be communicated to the routing system as they are brought into 
use. Similarly, when prefixes are released, they need to be removed from the routing system. 
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Different operators may have different policies regarding prefix lifetimes, and they may prefer to 
have centralized or distributed pools of spare prefixes. In an Autonomic Network, these are 
properties decided upon by the design of the relevant ASAs. The GRASP objectives are simply 
building blocks. 


A particular risk of distributed prefix allocation in large networks is that over time, it might lead 
to fragmentation of the address space and an undesirable increase in the size of the interior 
routing protocol tables. The extent of this risk depends on the algorithms and policies used by the 
ASAs. Mitigating this risk might even become an autonomic function in itself. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


This document uses terminology defined in [RFC7575]. 


3. Problem Statement 


The Autonomic Networking use case considered here is autonomic IPv6 prefix management at 
the edge of large-scale ISP networks. 


Although DHCPv6-PD (DHCPV6 Prefix Delegation) [RFC8415] supports automated delegation of 
IPv6 prefixes from one router to another, prefix management still largely depends on human 
planning. In other words, there is no basic information or policy to support autonomic decisions 
on the prefix length that each router should request or be delegated, according to its role in the 
network. Roles could be defined separately for individual devices or could be generic (edge 
router, interior router, etc.). Furthermore, IPv6 prefix management by humans tends to be rigid 
and static after initial planning. 


The problem to be solved by Autonomic Networking is how to dynamically manage IPv6 address 
space in large-scale networks, so that IPv6 addresses can be used efficiently. Here, we limit the 
problem to assignment of prefixes at the edge of the network, close to access routers that support 
individual fixed-line subscribers, mobile customers, and corporate customers. We assume that 
the core infrastructure of the network has already been established with appropriately assigned 
prefixes. The Autonomic Networking approach discussed in this document is based on the 
assumption that there is a generic discovery and negotiation protocol that enables direct 
negotiation between intelligent IP routers. GRASP [RFC8990] is intended to be such a protocol. 


3.1. Intended User and Administrator Experience 


The intended experience is, for the administrators of a large-scale network, that the management 
of IPv6 address space at the edge of the network can be run with minimum effort, as devices at 
the edge are added and removed and as customers of all kinds join and leave the network. In the 
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ideal scenario, the administrators only have to specify a single IPv6 prefix for the whole network 
and the initial prefix length for each device role. As far as users are concerned, IPv6 prefix 
assignment would occur exactly as it does in any other network. 


The actual prefix usage needs to be logged for potential offline management operations, 
including audit and security incident tracing. 


3.2. Analysis of Parameters and Information Involved 


For specific purposes of address management, each edge device will implement several 
parameters. (Some of them can be preconfigured before they are connected.) They include the 
following: 


e Identity, authentication, and authorization of this device. This is expected to use the 
Autonomic Networking secure bootstrap process [RFC8995], following which the device 
could safely take part in autonomic operations. 


e Role of this device. Some example roles are discussed in Section 6.1. 
e An IPv6 prefix length for this device. 
e An IPv6 prefix that is assigned to this device and its downstream devices. 


The network as a whole will implement the following parameters: 


e Identity of a trust anchor, which is a certification authority (CA) maintained by the network 
administrators, used during the secure bootstrap process. 


e Total IPv6 address space available for edge devices. It is a pool of one or several IPv6 
prefixes. 


e The initial prefix length for each device role. 


3.2.1. Parameters Each Device Can Define for Itself 


This section identifies those of the above parameters that do not need external information in 
order for the devices concerned to set them to a reasonable default value after bootstrap or after 
a network disruption. They are as follows: 


e Default role of this device. 
e Default IPv6 prefix length for this device. 
e Cryptographic identity of this device, as needed for secure bootstrapping [RFC8995]. 


The device may be shipped from the manufacturer with a preconfigured role and default prefix 
length, which could be modified by an autonomic mechanism. Its cryptographic identity will be 
installed by its manufacturer. 
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3.2.2. Information Needed from Network Operations 


This section identifies those parameters that might need operational input in order for the 
devices concerned to set them to a non-default value. 


e Non-default value for the IPv6 prefix length for this device. This needs to be decided based 
on the role of this device. 


e The initial prefix length for each device role. 
e Whether to allow the device to request more address space. 


e The policy regarding when to request more address space -- for example, if the address usage 
reaches a certain limit or percentage. 


3.2.3. Comparison with Current Solutions 


This section briefly compares the above use case with current solutions. Currently, the address 
management is still largely dependent on human planning. It is rigid and static after initial 
planning. Address requests will fail if the configured address space is used up. 


Some autonomic and dynamic address management functions may be achievable by extending 
the existing protocols -- for example, extending DHCPv6-PD [RFC8415] to request IPv6 prefixes 
according to the device role. However, defining uniform device roles may not be a practical task, 
as some functions cannot be configured on the basis of role using existing prefix delegation 
protocols. 


Using a generic autonomic discovery and negotiation protocol instead of specific solutions has 
the advantage that additional parameters can be included in the autonomic solution without 
creating new mechanisms. This is the principal argument for a generic approach. 


3.3. Interaction with Other Devices 


3.3.1. Information Needed from Other Devices 


This section identifies those of the above parameters that need external information from 
neighbor devices (including the upstream devices). In many cases, two-way dialogue with 
neighbor devices is needed to set or optimize them. 


e Information regarding the identity of a trust anchor is needed. 


e The device will need to discover another device from which it can acquire IPv6 address 
space. 


e Information regarding the initial prefix length for the role of each device is needed, 
particularly for its own downstream devices. 


e The default value of the IPv6 prefix length may be overridden by a non-default value. 


e The device will need to request and acquire one or more IPv6 prefixes that can be assigned 
to this device and its downstream devices. 


e The device may respond to prefix delegation requests from its downstream devices. 
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e The device may require the assignment of more IPv6 address space if it used up its assigned 
IPv6 address space. 


3.3.2. Monitoring, Diagnostics, and Reporting 


This section discusses what role devices should play in monitoring, fault diagnosis, and 
reporting. 


e The actual address assignments need to be logged for potential offline management 
operations. 


e In general, the usage situation regarding address space should be reported to the network 
administrators in an abstract way -- for example, statistics or a visualized report. 


e A forecast of address exhaustion should be reported. 


4. Autonomic Edge Prefix Management Solution 


This section introduces the building blocks for an autonomic edge prefix management solution. 
As noted in Section 1, this is not a complete description of a solution, which will depend on the 
detailed design of the relevant Autonomic Service Agents (ASAs). It uses the generic discovery 
and negotiation protocol defined by [RFC8990]. The relevant GRASP objectives are defined in 
Section 5. 


The procedures described below are carried out by an ASA in each device that participates in the 
solution. We will refer to this as the PrefixManager ASA. 


4.1. Behavior of a Device Requesting a Prefix 


If the device containing a PrefixManager ASA has used up its address pool, it can request more 
space according to its requirements. It should decide the length of the requested prefix and 
request it via the mechanism described in Section 6. Note that although the device's role may 
define certain default allocation lengths, those defaults might be changed dynamically, and the 
device might request more, or less, address space due to some local operational heuristic. 


A PrefixManager ASA that needs additional address space should firstly discover peers that may 
be able to provide extra address space. The ASA should send out a GRASP Discovery message that 
contains a PrefixManager Objective option (see Section 2 of [RFC8650] and Section 5.1) in order 
to discover peers also supporting that option. Then, it should choose one such peer, most likely 
the first to respond. 


If the GRASP Discovery Response message carries a Divert option pointing to an off-link 
PrefixManager ASA, the requesting ASA may initiate negotiation with that ASA-diverted device to 
find out whether it can provide the requested length of the prefix. 


In any case, the requesting ASA will act as a GRASP negotiation initiator by sending a GRASP 
Request message with a PrefixManager Objective option. The ASA indicates in this option the 
length of the requested prefix. This starts a GRASP negotiation process. 
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During the subsequent negotiation, the ASA will decide at each step whether to accept the offered 
prefix. That decision, and the decision to end the negotiation, are implementation choices. 


The ASA could alternatively initiate GRASP discovery in rapid mode with an embedded 
negotiation request, if it is implemented. 


4.2. Behavior of a Device Providing a Prefix 


At least one device on the network must be configured with the initial pool of available prefixes 
mentioned in Section 3.2. Apart from that requirement, any device may act as a provider of 
prefixes. 


A device that receives a Discovery message with a PrefixManager Objective option should 
respond with a GRASP Response message if it contains a PrefixManager ASA. Further details of 
the discovery process are described in [RFC8990]. When this ASA receives a subsequent Request 
message, it should conduct a GRASP negotiation sequence, using Negotiate, Confirm Waiting, and 
Negotiation End messages as appropriate. The Negotiate messages carry a PrefixManager 
Objective option, which will indicate the prefix and its length offered to the requesting ASA. As 
described in [RFC8990], negotiation will continue until either end stops it with a Negotiation End 
message. If the negotiation succeeds, the ASA that provides the prefix will remove the negotiated 
prefix from its pool, and the requesting ASA will add it. If the negotiation fails, the party sending 
the Negotiation End message may include an error code string. 


During the negotiation, the ASA will decide at each step how large a prefix to offer. That decision, 
and the decision to end the negotiation, are implementation choices. 


The ASA could alternatively negotiate in response to GRASP discovery in rapid mode, if it is 
implemented. 


This specification is independent of whether the PrefixManager ASAs are all embedded in 
routers, but that would be a rather natural scenario. In a hierarchical network topology, a given 
router typically provides prefixes for routers below it in the hierarchy, and it is also likely to 
contain the first PrefixManager ASA discovered by those downstream routers. However, the 
GRASP discovery model, including its redirection feature, means that this is not an exclusive 
scenario, and a downstream PrefixManager ASA could negotiate a new prefix with a device other 
than its upstream router. 


A resource shortage may cause the gateway router to request more resources in turn from its 
own upstream device. This would be another independent GRASP discovery and negotiation 
process. During the processing time, the gateway router should send a Confirm Waiting message 
to the initial requesting router, to extend its timeout. When the new resource becomes available, 
the gateway router responds with a GRASP Negotiate message with a prefix length matching the 
request. 


The algorithm used to choose which prefixes to assign on the devices that provide prefixes is an 
implementation choice. 
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4.3. Behavior after Successful Negotiation 


Upon receiving a GRASP Negotiation End message that indicates that an acceptable prefix length 
is available, the requesting device may use the negotiated prefix without further messages. 


There are use cases where the ANI/GRASP-based prefix management approach can work 
together with DHCPv6-PD [RFC8415] as a complement. For example, the ANI/GRASP-based 
method can be used intra-domain, while the DHCPv6-PD method works inter-domain (i.e., across 
an administrative boundary). Also, ANI/GRASP can be used inside the domain, and DHCP/ 
DHCPv6-PD can be used on the edge of the domain to clients (non-ANI devices). Another similar 
use case would be ANI/GRASP inside the domain, with RADIUS [RFC2865] providing prefixes to 
client devices. 


4.4. Prefix Logging 


Within the autonomic prefix management system, all prefix assignments are done by devices 
without human intervention. It may be required that all prefix assignment history be recorded -- 
for example, to detect or trace lost prefixes after outages or to meet legal requirements. However, 
the logging and reporting process is out of scope for this document. 


5. Autonomic Prefix Management Objectives 


This section defines the GRASP technical objective options that are used to support autonomic 
prefix management. 


5.1. Edge Prefix Objective Option 


The PrefixManager Objective option is a GRASP Objective option conforming to the GRASP 
specification [RFC8990]. Its name is "PrefixManager" (see Section 8), and it carries the following 
data items as its value: the prefix length and the actual prefix bits. Since GRASP is based on CBOR 
(Concise Binary Object Representation) [RFC8949], the format of the PrefixManager Objective 
option is described in the Concise Data Definition Language (CDDL) [RFC8610] as follows: 


objective = ["PrefixManager", objective-flags, loop-count, 
[length, ?prefix]] 


loop-count = @..255 ; as in the GRASP specification 
objective-flags /= ; as in the GRASP specification 
length = @..128 ; requested or offered prefix length 
prefix = bytes .size 16 ; offered prefix in binary format 


The use of the "dry run" mode of GRASP is NOT RECOMMENDED for this objective, because it 
would require both ASAs to store state information about the corresponding negotiation, to no 
real benefit -- the requesting ASA cannot base any decisions on the result of a successful dry-run 
negotiation. 
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5.2. IPv4 Extension 


This section presents an extended version of the PrefixManager objective that supports IPv4 by 
adding an extra flag: 


objective = ["PrefixManager", objective-flags, loop-count, prefval] 


loop-count = @..255 ; as in the GRASP specification 
objective-flags /= ; as in the GRASP specification 


prefval /= preféval 
pref6val = [version6, length, ?prefix] 
version6 = 6 


length = @..128 ; requested or offered prefix length 
prefix = bytes .size 16 ; offered prefix in binary format 
prefval /= pref4val 

pref4val = [version4, length4, ?prefix4] 

version4 = 4 

length4 = @..32 ; requested or offered prefix length 
prefix4 = bytes .size 4 ; offered prefix in binary format 


Prefix and address management for IPv4 is considerably more difficult than for IPv6, due to the 
prevalence of NAT, ambiguous addresses [RFC1918], and address sharing [RFC6346]. These 
complexities might require further extending the objective with additional fields that are not 
defined by this document. 


6. Prefix Management Parameters 


An implementation of a prefix manager MUST include default settings of all necessary 
parameters. However, within a single administrative domain, the network operator MAY change 
default parameters for all devices with a certain role. Thus, it would be possible to apply an 
intended policy for every device in a simple way, without traditional configuration files. As noted 
in Section 4.1, individual autonomic devices may also change their own behavior dynamically. 


For example, the network operator could change the default prefix length for each type of role. A 
prefix management parameters objective, which contains mapping information of device roles 
and their default prefix lengths, MAY be flooded in the network, through the Autonomic Control 
Plane (ACP) [RFC8994]. The objective is defined in CDDL as follows: 


objective = ["PrefixManager.Params", objective-flags, any] 
loop-count = @..255 ; as in the GRASP specification 


objective-flags /= ; as in the GRASP specification 


The "any" object would be the relevant parameter definitions (such as the example below) 
transmitted as a CBOR object in an appropriate format. 
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This could be flooded to all nodes, and any PrefixManager ASA that did not receive it for some 
reason could obtain a copy using GRASP unicast synchronization. Upon receiving the prefix 
management parameters, every device can decide its default prefix length by matching its own 
role. 


6.1. Example of Prefix Management Parameters 


The parameters comprise mapping information of device roles and their default prefix lengths in 
an autonomic domain. For example, suppose an IPRAN (IP Radio Access Network) operator 
wants to configure the prefix length of a Radio Network Controller Site Gateway (RSG) as 34, the 
prefix length of an Aggregation Site Gateway (ASG) as 44, and the prefix length of a Cell Site 
Gateway (CSG) as 56. This could be described in the value of the PrefixManager.Params objective 
as: 


[[ "role", "RSG"],["prefix_length", 34]], 
[["role", "ASG"],["prefix_length", 44]], 
[["role", "CSG"],["prefix_length", 56]] 


This example is expressed in JSON [RFC8259], which is easy to represent in CBOR. 


An alternative would be to express the parameters in YANG [RFC7950] using the YANG-to-CBOR 
mapping [CORE-YANG-CBOR]. 


For clarity, the background of the example is introduced below and can also be regarded as a use 
case for the mechanism defined in this document. 


An IPRAN is used for mobile backhaul, including radio stations, RNCs (Radio Network 
Controllers) (in 3G) or the packet core (in LTE), and the IP network between them, as shown in 
Figure 1. The eNB (Evolved Node B) entities, the RNC, the SGW (Serving Gateway), and the MME 
(Mobility Management Entity) are mobile network entities defined in 3GPP. The CSGs, ASGs, and 
RSGs are entities defined in the IPRAN solution. 


The IPRAN topology shown in Figure 1 includes Ring1, which is the circle following ASG1->RSG1- 
>RSG2->ASG2->ASG1; Ring2, following CSG1->ASG1->ASG2->CSG2->CSG1; and Ring3, following 
CSG3->ASG1->ASG2->CSG3. In a real deployment of an IPRAN, there may be more stations, rings, 
and routers in the topology, and normally the network is highly dependent on human design and 
configuration, which is neither flexible nor cost-effective. 
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Figure 1: IPRAN Topology Example 


If ANI/GRASP is supported in the IPRAN, the network nodes should be able to negotiate with each 
other and make some autonomic decisions according to their own status and the information 
collected from the network. The prefix management parameters should be part of the 
information they communicate. 


The routers should know the role of their neighbors, the default prefix length for each type of 
role, etc. An ASG should be able to request prefixes from an RSG, and a CSG should be able to 
request prefixes from an ASG. In each request, the ASG/CSG should indicate the required prefix 
length, or its role, which implies what length it needs by default. 


7. Security Considerations 


Relevant security issues are discussed in [RFC8990]. The preferred security model is that devices 
are trusted following the secure bootstrap procedure [RFC8995] and that a secure Autonomic 
Control Plane (ACP) [RFC8994] is in place. 


It is RECOMMENDED that DHCPv6-PD, if used, should be implemented using DHCPv6 


authentication or Secure DHCPV6. 


8. IANA Considerations 


This document defines two new GRASP Objective option names: "PrefixManager" and 
"PrefixManager.Params". The IANA has added these to the "GRASP Objective Names" registry 
defined by [RFC8990]. 
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Appendix A. Deployment Overview 


This appendix includes logical deployment models and explanations of the target deployment 
models. Its purpose is to help in understanding the mechanism described in this document. 


This appendix includes two subsections: Appendix A.1 for the two most common DHCP 
deployment models and Appendix A.2 for the PD deployment model described in this document. 
It should be noted that these are just examples, and there are many more deployment models. 


Jiang, et al. 


Informational Page 14 


RFC 8992 Auto IPv6 Prefix Management May 2021 


A.1. Address and Prefix Management with DHCP 


Edge DHCP server deployment requires every edge router connecting to a Customer Premises 
Equipment (CPE) device to be a DHCP server assigning IPv4/IPv6 addresses to CPEs -- and, 
optionally, IPv6 prefixes via DHCPv6-PD for IPv6-capable CPEs that are routers and have LANs 
behind them. 


edge 
dynamic, "NETCONF/YANG" interfaces 
<--------------- > +------------- + 
+------ + <- telemetry | edge router/|-+ ----- +----- + 
|config| .... domain... | DHCP server I: | CPE |+ LANs 
|server | GIS esSea peas cf (| ess ea a) Ces=| 3 
+------ + +-------------- + DHCP/ +----- + 
DHCPv6-PD 


Figure 2: DHCP Deployment Model without a Central DHCP Server 


This requires various coordination functions via some backend system (depicted as the "config 
server" in Figure 2): the address prefixes on the edge interfaces should be slightly larger than 
required for the number of CPEs connected so that the overall address space is best used. 


The config server needs to provision edge interface address prefixes and DHCP parameters for 
every edge router. If prefixes that are too fine-grained are used, this will result in large routing 
tables across the domain shown in the figure. If prefixes that are too coarse-grained are used, 
address space is wasted. (This is less of a concern for IPv6, but if the model includes IPV4, it is a 
very serious concern.) 


There is no standard that describes algorithms for how configuration servers would best 
perform this ongoing dynamic provisioning to optimize routing table size and address space 
utilization. 


There are currently no complete YANG data models that a config server could use to perform 
these actions (including telemetry of assigned addresses from such distributed DHCP servers). 
For example, a YANG data model for controlling DHCP server operations is still being developed 
[DHCP-YANG-MODEL]. 


Due to these and other problems related to the above model, the more common DHCP 
deployment model is as follows: 
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+------ + edge 
|config| imit iali neig interfaces 
|SGIRVGle |) m nnmn ZEE a Ar 
pI + | edge router/|-+ ----- ait F 
| wae domain . 2. | DHCP relay | |... | CPE |+ LANs 
+------ + +------------- + | ----- +----- +| (---| ) 
|DHCP | a lc + o DHCP/ aiuto + 
| server | DHCPv6-PD 
+------ + 


Figure 3: DHCP Deployment Model with a Central DHCP Server 


Dynamic provisioning changes to edge routers are avoided by using a central DHCP server and 
reducing the edge router from DHCP server to DHCP relay. The "configuration" on the edge 
routers is static. The DHCP relay function inserts an "edge interface" and/or subscriber- 
identifying options into DHCP requests from CPEs (e.g., [RFC3046] [RFC6221]), and the DHCP 
server has complete policies for address assignments and prefixes usable on every edge router / 
interface / subscriber group. When the DHCP relay sees the DHCP reply, it inserts static routes for 
the assigned address / address prefix into the routing table of the edge router; these routes are 
then to be distributed by the IGP (or BGP) inside the domain to make the CPE and LANs reachable 
across the domain shown in the figure. 


There is no comprehensive standardization of these solutions. For example, [RFC8415], Section 
19.1.3 simply refers to "a [non-defined] protocol or other out-of-band communication to 
configure routing information for delegated prefixes on any router through which the client may 
forward traffic." 


A.2. Prefix Management with ANI/GRASP 


Using the ANI and prefix management ASAs (PM-ASAs) using GRASP, the deployment model is 
intended to look as follows: 
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toe mene ce cea ANI domain / SAGRee er ere >| ( Ne eer eae => 
Roles 
| 
v "Edge routers" 
GRASP parameter +---------- + 
Network-wide | PM-ASA | downstream 
parameters/policies | (DHCP | interfaces 
l |functions)| ------ 
v "central device" +---------- + 
+------ + A +-------- + 
| PM-ASA | Ce ee eee GRASP .... .... | CPE [-+ (LANs) 
ne + v |(PM-ASA)| | ---| 
7 E eee +  +---------- + +-------- + | 
iy iA ave aes + . PM-ASA . | PM-ASA | ------ oaaao + 
.DHCP server. ELE: + | (DHCP | SLAAC/ 
PE E + "intermediate |functions) | DHCP/DHCP-PD 
router" +---------- + 


Figure 4: Deployment Model Using ANI/GRASP 


The network runs an ANI domain with an ACP [RFC8994] between some central device (e.g., a 
router or an ANI-enabled management device) and the edge routers. ANI/ACP provides a secure, 
zero-touch communication channel between the devices and enables the use of GRASP [RFC8990] 
not only for peer-to-peer communication but also for distribution/flooding. 


The central devices and edge routers run software in the form of ASAs to support this document's 
autonomic IPv6 edge prefix management. PM-ASAs as discussed below together comprise the 
Autonomic Prefix Management Function. 


Edge routers can have different roles based on the type and number of CPEs attaching to them. 
Each edge router could be an RSG, ASG, or CSG in mobile aggregation networks (see Section 6.1). 
Mechanisms outside the scope of this document make routers aware of their roles. 


Some considerations related to the deployment model are as follows. 


1. In a minimum prefix management solution, the central device uses the 
PrefixManager.Params GRASP objective introduced in this document to disseminate 
network-wide, per-role parameters to edge routers. The PM-ASA uses the parameters that 
apply to its own role to locally configure preexisting addressing functions. Because the PM- 
ASA does not manage the dynamic assignment of actual IPv6 address prefixes in this case, 
the following options can be considered: 

1.a The edge router connects via downstream interfaces to each (host) CPE that requires 
an address. The PM-ASA sets up for each such interface a DHCP requesting router 
(according to [RFC8415]) to request an IPv6 prefix for the interface. The router's 
address on the downstream interface can be another parameter from the GRASP 
objective. The CPEs assign addresses in the prefix via Router Advertisements (RAs), or 
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the PM-ASA manages a local DHCPV6 server to assign addresses to the CPEs. A central 
DHCP server acting as the DHCP delegating router (according to [RFC8415]) is 
required. Its address can be another parameter from the GRASP objective. 


1.b The edge router also connects via downstream interfaces to (customer managed) CPEs 
that are routers and act as DHCPV6 requesting routers. The need to support this could 
be derived from role or GRASP parameters, and the PM-ASA sets up a DHCP relay 
function to pass on requests to the central DHCP server as in point 1.a. 


2. In a solution without a central DHCP server, the PM-ASA on the edge routers not only learns 
parameters from PrefixManager.Params but also utilizes GRASP to request/negotiate actual 
IPv6 prefix delegation via the GRASP PrefixManager objective, as described in more detail 
below. In the simplest case, these prefixes are delegated via this GRASP objective from the 
PM-ASA in the central device. This device must be provisioned initially with a large pool of 
prefixes. The delegated prefixes are then used by the PM-ASA on the edge routers to 
configure prefixes on their downstream interfaces to assign addresses via RA/SLAAC to host 
CPEs. The PM-ASA may also start local DHCP servers (as in point 1.a) to assign addresses via 
DHCP to the CPEs from the prefixes it received. This includes both host CPEs requesting IPv6 
addresses and router CPEs that request IPv6 prefixes. The PM-ASA needs to manage the 
address pool(s) it has requested via GRASP and allocate sub-address pools to interfaces and 
the local DHCP servers it starts. It needs to monitor the address utilization and accordingly 
request more address prefixes if its existing prefixes are exhausted, or return address 
prefixes when they are unneeded. 


This solution is quite similar to the previous IPv6 DHCP deployment model without a central 
DHCP server, and ANI/ACP/GRASP and the PM-ASA do provide the automation to make this 
approach work more easily than is possible today. 


oO 


. The address pools from which prefixes are allocated do not all need to be taken from one 
central location. An edge-router PM-ASA that received a big (short) prefix from a central PM- 
ASA could offer smaller sub-prefixes to a neighboring edge-router PM-ASA. GRASP could be 
used in such a way that the PM-ASA would find and select the objective from the closest 
neighboring PM-ASA, therefore allowing aggregation to be maximized: a PM-ASA would only 
request further smaller prefixes when it exhausts its own pool (from the central location) 
and cannot get further large prefixes from that central location anymore. Because the 
overflow prefixes taken from a topologically nearby PM-ASA, the number of longer prefixes 
that have to be injected into the routing tables is limited and the topological proximity 
increases the chances that aggregation of prefixes in the IGP can most likely limit the 
geography in which the longer prefixes need to be routed. 


4. Instead of peer-to-peer optimization of prefix delegation, a hierarchy of PM-ASAs can be built 
(indicated in Figure 4 via a dotted intermediate router). This would require additional 
parameters in the PrefixManager objective to allow the creation of a hierarchy of PM-ASAs 
across which the prefixes can be delegated. 


5. In cases where CPEs are also part of the ANI domain (e.g., "managed CPEs"), then GRASP will 
extend into the actual customer sites and can also run a PM-ASA. All the options described in 
points 1 to 4 above would then apply to the CPE as the edge router, with the major changes 
being that (a) a CPE router will most likely not need to run DHCPV6-PD itself, but only DHCP 
address assignment and (b) the edge routers to which the CPE connects would most likely 
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become ideal places on which to run a hierarchical instance of PD-ASAs, as outlined in point 
1. 
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